home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17551 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: ghost.shsu.edu!usenet
  2. From: Rick Mehalick <rmehalic@i-o.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why don't you use garbage collection
  5. Date: Tue, 16 Apr 1996 08:14:51 -0500
  6. Organization: Sam Houston State University
  7. Message-ID: <31739D4B.2305@i-o.com>
  8. References: <AD94A731966836BF@dialup97-6-14.swipnet.se> <1996Apr16.110526.1846@ittpub>
  9. NNTP-Posting-Host: 205.241.79.114
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.4 sun4d)
  14.  
  15. Wil Evers wrote:
  16. > 
  17. > In article <AD94A731966836BF@dialup97-6-14.swipnet.se> lars.farm@nts.mh.se
  18. > (Lars Farm) writes:
  19. > > In article <AUSTERN.96Apr12095652@isolde.mti.sgi.com>,
  20. > > austern@isolde.mti.sgi.com (Matt Austern) wrote:
  21. > >
  22. > > >In C++ we're used to the idea that heap-allocated and stack-allocated
  23. > > >objects have different rules.  It's not so radical to introduce
  24. > > >garbage-collected objects as a third category.
  25. > >
  26. > > My sentiments exactly.
  27. > 
  28. > OK, let's get serious about this:
  29. > 
  30. > 1. Don't we think C++ is complex enough as it is?  In my experience, the
  31. > main obstacle to get people to use C++ is its steep learning curve, and
  32. > adding yet a third category of objects wouldn't make things any easier.
  33. > 
  34. > 2. Will the destructors of garbage collected objects be called?
  35. > 
  36. > 3. If the answer to (2) is NO: how do we make sure we don't get resource
  37. > leaks for non-memory resources?
  38. > To elaborate: IMHO, the type of resources used by a particular class is an
  39. > implementation detail its users should not have to know or worry about,
  40. > and implementers should be able to change that without affecting the
  41. > users.
  42. > But even if we drop this constraint, derived classes should be able to use
  43. > additional resource types without changing the `garbage collectability' of
  44. > objects accessed through the base class interface.
  45. > 
  46. > 4. If the answer to (2) is YES: when will these destructors be called?
  47. > What can we assume about the state of the program when the destructor
  48. > runs?  How do we guarantee a shortage of non-memory resources is detected
  49. > by the garbage collector before we get to the point where the program
  50. > can't continue?
  51. > 
  52. > - Wil
  53.  
  54. Garbage collection for C and C++ caan be done with a product called
  55. Great Circle.  It seems to work very well.
  56.  
  57. -- 
  58. Rick Mehalick
  59.